[Previous] [Next] [Index] [Thread]

Re: Redundant web pages

On Tue, 14 May 1996 lazear@gateway.mitre.org wrote:

> If one wants to provide a web page that is always available,
> what mechanisms are available to create this redundant capability?
> I know about round-robin DNS that gives a new address from a pool
> of servers, but caching the answer means a client won't ask for a
> new address for hours (so for them, the page is down).  What other
> means of having a redundant web page are there?  Thanks for any
> suggestions.

  From the "unofficial" BIND FAQ:

  ftp://ftp.njit.edu/pub/dns/cptd.faq

Q4.10:
 
Q: If you attempt to distribute the load on a system using named, won't 
   the first response be cached, and then later queries use the cached
   value? (This would be for requests that come through the same
   server.)
 
A: Yes.  So it can be useful to use a lower TTL on records where this is
   important.  You can use values like 300 or 500 seconds.

   If your local caching server has ROUND_ROBIN, it does not matter
   what the authoritative servers have -- every response from the cache
   is rotated.

   But if it doesn't, and the authoritative server site is depending on
   this feature (or the old "shuffle-A") to do load balancing, then if
   one doesn't use small TTLs, one could conceivably end up with a
   really nasty situation, e.g., hundreds of workstations at a branch
   campus pounding on the same front end at the authoritative server's
   site during class registration.

   Not nice.

A: Paul Vixie has an example of the ROUND_ROBIN code in action.  Here is 
   something that he wrote regarding his example:

     >I want users to be distributed evenly among those 3 hosts.

     Believe it or not :-), BIND offers an ugly way to do this.  I offer
     for your collective amusement the following snippet from the
     ugly.vix.com zone file:

       hydra           cname        hydra1
                       cname        hydra2
                       cname        hydra3
       hydra1          a            10.1.0.1
                       a            10.1.0.2
                       a            10.1.0.3
       hydra2          a            10.2.0.1
                       a            10.2.0.2
                       a            10.2.0.3
       hydra3          a            10.3.0.1
                       a            10.3.0.2
                       a            10.3.0.3
       
      Note that having multiple CNAME RR's at a given name is
      meaningless according to the DNS RFCs but BIND doesn't mind (in
      fact it doesn't even complain).  If you call
      gethostbyname("hydra.ugly.vix.com") (try it!) you will get
      results like the following.  Note that there are two round robin
      rotations going on: one at ("hydra",CNAME) and one at each
      ("hydra1",A) et al.  I used a layer of CNAME's above the layer of
      A's to keep the response size down.  If you don't have nine
      addresses you probably don't care and would just use a pile of
      CNAME's pointing directly at real host names.

  So, one option is to set the TTL (time to live) on the record down to 
something small.  This will increase the load on your DNS servers, but 
this can be a useful tradeoff.

  You can also use the abstraction above as well.

  A resolver will return multiple addresses if they are associated with a 
given name.  A client can choose to do nice things like try the other 
addresses if it gets a "connection refused" from attempting to open the 
socket connection.  Netscape seems to do this, although I haven't tested 
it.

  Also, many operating systems (Solaris, Linux?, SunOS, BSDI) support 
the aliasing of multiple IP addresses onto a single physical network 
interface.  This allows you to run "virtual hosts", as you can have 
multiple HTTP servers running, each which bind to and listen for a 
different address, and have a different document root directory.  Netsite 
supports this, as does the NCSA-derived servers (Apache, etc.)

  So, if server X goes down, bring up its IP address and data on another 
machine.  You'd have to do it manually, of course, which may not be what 
you want.

  Some high-availability hardware platforms offer something similar to 
this on a grander scale.  SGI and DEC offer this, as does Sun 
apparently.  Two machines running in parallel can take over for each 
other if one dies.

  The above more or less covers the questions of loss of a server process 
or hardware.  Data is another question for high-availability.  AFS 
(Transarc's Andrew File System) offers data replication which can 
accomplish this.  In parallel with multiple A records and virtual 
interfaces, you can put together a very highly available Web site.

  Sun's Solsite Disk Suite 4.0, RAID, and other driver-level products can 
in addition offer protection against loss of data due to hardware 
failures by replicating data onto multiple devices or allowing data to be 
reconstituted if a single component fails.

  So, in summary, you can offer redundancy at several points:

  - DNS
  - Network Address
  - Hardware Failover
  - Data Filesystem-level Replication
  - Data Device-level Replication

  Depending on your needs and budget, a solution or combination of 
solutions may be in order.

  -brian
--
  Brian W. Spolarich - ANS CO+RE Systems - briansp@ans.net - (313)677-7311
This message has been brought to you by the letters Q and X and the number 3.
References: